Performance optimization

Vid design och uppbyggnad av webbplatser och intranät måste man tänka igenom vilka krav man har på systemet. För att få korta svarstider, goda möjligheter till lagring och hög driftsäkerhet måste ofta göra olika typer av optimeringar. Detta får sedan inverkan på hur man bygger upp webbplatsen och vilken hårdvara man har till servern. Generellt sett är det tre faktorer som påverkar prestandan:

• Antalet samtidiga besökare/användare
• Mängden data som överförs
• Hur krävande (komplext) det är att skapa den information som ska presenteras.

Webbplatser med många samtidiga besökare utsätter involverade servrar för hög last jämfört med webbplatser med få samtidiga besökare. Intranät med många samtidiga användare renderar ofta ännu högre last jämfört med samma antal besökare på en publik/anonym webbplats. Det är framför allt webbservern som belastas av många användare.

Använda cache för att öka prestanda

Vid dimensionering och uppbyggnad av infrastrukturen för en större webbplats brukar många tala om dynamiska eller statiska eller webbplatser, eller en blandning av dessa:

I de flesta fall är webbplatsen uppbyggd av en blandning av dynamiskt och statiskt innehåll, dvs med ett mixat innehåll. Fördelningen mellan dynamiskt och statiskt innehåll varierar naturligtvis, men det är relativt vanligt med en fördelning på ca 50% dynamiskt och ca 50% statiskt innehåll. Många hårdvaruleverantörer använder begreppen Dynamic Content och Static Content i de dimensioneringsguider de tillhandahåller för val av hårdvara.

Dynamiskt innehåll genereras oftast genom någon form av databasanrop vilket betyder att dynamiskt innehåll renderar mest last på databasen - i de flesta fall är anrop till Content Studio XML-index de mest påfrestande delarna. Statiskt innehåll kan däremot oftast cachas vilket leder till mer last på webbservern och en mindre last på SQL Server.

En genomtänkt, väl uppbyggd och ordentligt cachad lösning kan vara över 100 gånger mer lättdriven än en ej optimerad lösning. Att uppnå 100 gånger bättre prestanda via mjukvaruoptimering är betydligt billigare än att investera i 100 gånger mer kraftfull hårdvara. Belastningstester har visat att effektiv cachning av sidor på en webserver kan öka sin effektiviten från max 40 request per sekund, till över 4000 request per sekund - en förbättring på 10,000%.

Alla webbsidor är dock i praktiken inte lämpliga att cacha och ibland är det tekniskt omöjligt att cacha sidor. Men även om inte alla webbsidor går att cacha är det viktigt att cacha de webbsidor som går att cacha - många bäckar små gör tillsammans och i slutändan en stor skillnad i belastning. Genom att cacha webbsidor frigörs resurser som kan användas för de webbsidor som inte kan cachas.

Teknikhusets erfarenhet av uppbyggnad av större webbplatser, cachning av dessa och val av lämplig hårdvara talar ett enhetligt språk: det är ytterst viktigt att bygga upp webbplatsen på ett sätt som möjliggör cachning av sidorna - en ökning av antalet cachade sidor ger en direkt förbättrad prestanda.

Mer detaljer kring hur man använder cache finns i kapitlet Cache management.

Rekommendationer för hårdvara

En generell rekommendation för hårdvarudimensionering är att servern som kör Microsoft SQL Server bör vara den kraftfullaste maskinen - speciallt för mer dynamiska webbplatser. Om webbplatsen däremot är mer statisk, och därmed kan cachas i större utsträckning, kommer webbservern troligen att belastas mer än SQL Server. En fullt cachad webbplats renderar i stort sett ingen trafik till SQL Server - istället ligger lasten i stort sett helt på webbservern och cachetekniken i Microsoft .NET Framework. Tester har visat att en väl cachad webbplats skapad i Content Studio, driven av en enkel processor (Intel Pentium P4 3,2 GHz), kan leverera över 4000 request per sekund. Testet mätte upp en nätverkstrafik på hela 88Mb XHTML/sekund vilket i stort sett motsvarar en fullt utnyttjad gigabitanslutning använd i testet. Å andra sidan påvisade testet att motsvarande webbplats, inställd att drivas helt helt utan cache, renderade 100% CPU last på SQL Server och webbplatsen kunde endast besvara ca 40 request per sekund.

Nedanstående punkter kan ses som generella rekomendationer för uppbyggnad och infrastruktur för en större publik webbplats:

• Om möjligt, dela upp driften på minst två servrar; en för Microsoft SQL Server och en för webbservern
• Använd helst dedikerade nätverkskort mellan webbserver och SQL Server. Minst 1Gbit anslutningshastighet rekommenderas.
• Dimensionera alltid SQL Server som den kraftfullare servern
• Välj gärna hårdvara för SQL Server som använder flera processorkärnor (exempelvis dual- eller quad core). Denna typ av processorer ger större kraft utan att öka licenskostnaden för Microsoft SQL Server i motsvarande utsträckning.
• Mänden internminne på SQL Server bör helst vara minst dubbelt så stort som storleken på databasen
• Disksystemen till de anslutna servrarna bör helst vara baserade på Raid>3, eller ännu bättre ett högpresterande SAN med en anslutningshastighet på minst 4Gbit/sek.
• Disksystemet för SQL Server bör helst vara uppdelat på två separata I/O kanaler - en kanal optimerad för skrivning av logfilen, och en kanal optimerad för läsning/skrivning/failover av databasen.
• Om möjligt, välj Microsoft SQL Server 2005 64-bit edition
• Om möjligt, kör SQL Server på ett 64-bitars operativsystem, och på en eller flera 64-bitars processorer. Exempelvis Microsoft Windows Server 2003 R2 64-bit edition i kombination med Intel Xeon processor.
• Om möjligt, cacha hela webbsidor istället för AS-komponenter
• Cacha så många helsidor som möjligt. Cachning av helsidor ger bättre prestanda än cachning av delsidor (includes).
• Cacha helst helsidor upstream och clientside.
• Cacha så många inkluderade sidor som möjligt
• Cacha så många AS-komponenter som möjligt
• Använd gärna applikationsvariabler för cachning av data, exempelvis inställningar
• Utför alltid belastningstester INNAN driftsättning (exempelvis Microsoft Web Application Stress Tool och Microsoft WCAT i kombination med Performance Monitor).
• Analysera trafiken/förfrågningarna till SQL Server och försök identifiera och optimera de mest processorkrävande urvalsfrågorna. I de flesta fall renderar anrop till XML-index den största belastningen.
• Unvik speciellt SQL frågor till XML-index som renderar sk. rowscanning - dvs frågor som inte kan utnyttja index i SQL Server.
• Använd gärna externa proxyservrar för ytterligare lastfördelning och optimering
• Välj hårdvara som kan uppgraderas i avseende ytterligare processorer och mer internminne

Mer detaljer kring hårdvara och mjukvara finns i kapitlet Content Studio Architecture.

Tips för prestandaoptimering

Prestandatester

Microsoft Web Application Stress Tool 

The Microsoft WAS web stress tool is designed to realistically simulate multiple browsers requesting pages from a web site. You can use this tool to gather performance and stability information about your web application. This tool simulates a large number of requests with a relatively small number of client machines. The goal is to create an environment that is as close to production as possible so that you can find and eliminate problems in the web application prior to deployment.

For more information, see Microsoft Web Application Stress Tool

Microsoft WCAT

The Microsoft Web Capacity Analysis Tool (WCAT) runs simulated workloads on client-server configurations. Using WCAT, you can test how your Internet Information Services and network configuration respond to a variety of different client requests for content, data, or Hypertext Markup Language (HTML) pages. The results of these tests can be used to determine the optimal server and network configuration for your computer. WCAT is specially designed to valuate how Internet servers running Windows 2000 (or Windows NT) and Internet Information Services respond to various client workload simulations.

You can test different server and network configurations by using the prepared WCAT content and workload simulations. When you change your hardware and software configuration and repeat the prepared tests, you can identify how the new configuration affects server response to the simulated client workload. You can use WCAT to test servers with single or multiple processors and to test servers that are connected to multiple networks.